Most current systems have difficulties handling multiple versions of a computer program. One problem is that storing multiple versions of a program requires a large amount of storage space. Another problem is that different versions of the program have to have different names which requires administrative coordination in a multi-user system in which different versions of the programs are being used by different individuals.
Software users also typically prefer to have access to more than one version of a program. However, before discussing some conventional methods for providing more than one version and their associated drawbacks, the reasons behind why there are typically multiple versions of a program will be briefly discussed.
In order to manage development of a computer program, a software developer often modularizes the computer program into several interrelated modules. For example, the developer of a large data processing program might divide a program into separate main, read, compute and print modules. Accordingly, the main, read, compute and print modules contain the portions of the program pertaining to controlling the program, reading data, processing data, and printing results, respectively.
When the program reaches the commercial environment, it becomes a product and has a product life cycle. During the product life cycle of a program, software developers may modify an initial revision of a module, i.e., the original version of the module. This is accomplished by creating a copy of the initial revision, changing the copy and storing the copy as a new revision. For instance, part of the program may not operate correctly and the developer may need to change a section of source code to fix the error. The developer may also wish to add an enhancement to the program. Modification of an initial module revision results in a module having two revisions and the program having two versions, the first version being generated from the initial revision and the second version being generated from the new revision.
Typically, software developers store all the module revisions for a program in one directory, i.e., a conventional system of structuring modules. For example, the module revisions needed to generate a program named "my.sub.-- prog" may include modules named "main", "read", "comp" and "print". Software developers typically rename the second revision of a module, since most computer platforms, i.e., the combination of computer hardware and software, do not permit multiple files such as module revisions to exist in the same subdirectory with the same name. For instance, if the modules are written in the C programming language, the initial revision of the "read" module might be called "read.c" and stored in a directory, and the new revision might be called "read2.c" and stored in the same directory.
Additionally, software developers usually use a conventional program construction procedure, which is commonly referred to as a build procedure, to construct a version of a program from the module revisions stored in a single directory. The software developer must modify the program construction procedure to accommodate each new revision of a module. Thus, the program construction procedure, for the example above, must be modified to use "read2.c" for constructing the second version of the "my prog" program.
Software users often prefer to have both an old version and a new version of a program available. For example, the user may wish to keep the original version of the "my.sub.-- prog" program since the new version of the "my.sub.-- prog" program may no longer support reading an old datafile, and may wish to use the new version of the "my.sub.-- prog" program in order to utilize a new enhancement that is not available with the original version. A conventional solution to providing access to both the new version and the old version is to store both versions of the program on the computer system.
However, storing two or more versions of a program on the same computer system has several drawbacks. One drawback is that storing multiple versions of a program wastes disk space. This drawback is particularly pronounced when each version is very large. For instance, four versions of an original 80 MB program might require 320 MB of disk space if all versions are to be stored.
Another drawback is that many computer platforms prohibit two versions of a program from existing together in the same subdirectory with the same name, as described earlier with respect to storing multiple module revisions on the same computer platform. One solution to overcome this drawback is for the user to rename the second version of the program so that both versions can be stored in the same subdirectory. However, this solution creates other drawbacks if the version is invoked or "called" by a another program referred to as a "calling" program.
A user typically modifies a calling program each time the user wishes to have the calling program use a different version of the called program. In the example above, where the first version of the "my.sub.-- prog" program is named "my.sub.-- prog" and the second version is named "my.sub.-- prog2", the user would typically change a variable of the calling program from "my.sub.-- prog" to "my.sub.-- prog2". However, this cannot be done if the version name is "hardcoded" into the calling program, i.e., if the calling program is in executable form and cannot be modified.
Another solution is to store each version of the called program in a different directory. In this case, the user must swap the versions between directories so that the calling program uses the correct version of the called program. Alternatively, different paths may be specified or the directory must be specified. Additionally, the user must remember where each version of the called program is located and which version is presently being used. It should be apparent that this solution requires a considerable amount of time and effort from the user. An additional problem is that sometimes a program expects that data used by it is located in a directory relative to the directory in which the program is found. That is, generally speaking, a program assumes that it operates and exists in a particular environment. This assumption is hard-coded in the program.
In view of the above-described drawbacks to the conventional system, it would be very useful to provide a system that enables a user to access multiple versions of a program while saving disk space. Furthermore, it would also be very useful to provide a system that reduces the amount of time and effort that a user expends when making a calling program use a new version of a called program.